\subsubsection{ARM}

\myparagraph{\OptimizingKeilVI (\ThumbMode)}

\lstinputlisting[style=customasmARM]{patterns/04_scanf/1_simple/ARM_IDA.lst}

\myindex{\CLanguageElements!\Pointers}

Afin que \scanf puisse lire l'item, elle a besoin d'un paramètre---un pointeur sur un \Tint.
Le type \Tint est 32-bit, donc nous avons besoin de 4 octets pour le stocker quelque
part en mémoire, et il tient exactement dans un registre 32-bit.
\myindex{IDA!var\_?}
De l'espace pour la variable locale \GTT{x} est allouée sur la pile et \IDA l'a
nommée \IT{var\_8}. Il n'est toutefois pas nécessaire de définir cette macro, puisque
le \ac{SP} (\glslink{stack pointer}{pointeur de pile}) pointe déjà sur cet espace et
peut être utilisé directement.

Doc, la valeur de \ac{SP} est copiée dans la registre \Reg{1} et, avec la chaîne
de format, passée à \scanf.
\myindex{ARM!\Instructions!LDR}
Plus tard, avec l'aide de l'instruction \INS{LDR}, cette valeur est copiée depuis
la pile vers le registre \Reg{1} afin de la passer à \printf.

\myparagraph{ARM64}

\lstinputlisting[caption=GCC 4.9.1 ARM64 \NonOptimizing,numbers=left,style=customasmARM]{patterns/04_scanf/1_simple/ARM64_GCC491_O0_FR.s}

Il y a 32 octets alloués pour la structure de pile, qui est plus que nécessaire.
Peut-être dans un soucis d'alignement de mémoire?
La partie la plus intéressante est de trouver de l'espace pour la variable $x$ dans
la structure de pile (ligne 22).
Pourquoi 28? Pour une certaine raison, le compilateur a décidé de stocker cette
variable à la fin de la structure de pile locale au lieu du début.
L'adresse est passée à \scanf, qui stocke l'entrée de l'utilisateur en mémoire à
cette adresse.
Il s'agit d'une valeur sur 32-bit de type \Tint.
La valeur est prise à la ligne 27 puis passée à \printf.

